Summary

Enterprise HSM signers (GaraSign, ESRP, SignServer, Venafi) produce MCPB bundles that Claude Desktop rejects. The root cause: external signers append PKCS#7 signatures after the ZIP EOCD without updating comment_length, causing adm-zip to reject the file with "Invalid comment length."

This PR adds two new CLI commands that implement a pre-signing preparation workflow — the signer operates on content that already has the correct EOCD metadata, so no post-signing fixup is needed:

# Step 1: Pre-allocate signature space in the ZIP EOCD
mcpb prepare-for-signing bundle.mcpb

# Step 2: Sign with any enterprise HSM (detached PKCS#7, DER format)
# (GaraSign, ESRP, SignServer, Venafi, Azure SignTool, etc.)

# Step 3: Embed the detached signature into the pre-allocated slot
mcpb apply-signature bundle.mcpb --signature sig.p7s

Supersedes #220. Complementary to #195 — once that verify fix merges, mcpb verify will validate bundles produced by this workflow with no additional changes needed (the signature covers content with the correct comment_length, so no EOCD reversal is required).

Why this works

The key insight is when the EOCD is modified relative to signing:

Reference implementation

This generalizes the pattern that Microsoft's Azure MCP Server team already ships in production:

• eng/scripts/Stage-McpbForSigning.ps1 → mcpb prepare-for-signing
• eng/scripts/Apply-McpbSignatures.ps1 → mcpb apply-signature

Microsoft's signed Azure MCP bundles (beta.22 through beta.33) have been installing successfully in Claude Desktop using this exact pattern. Our output is byte-for-byte format-compatible with theirs (16384-byte padded signature block, MCPB_SIG_V1/MCPB_SIG_END markers, zero-padded DER PKCS#7).

What's included

src/node/sign.ts:

• prepareForExternalSigning() — sets EOCD comment_length to 16384, validates not already signed/prepared
• applyExternalSignature() — embeds detached PKCS#7 into pre-allocated slot with zero-padding
• MAX_SIG_BLOCK_SIZE constant (16384, matching Microsoft's pipeline)

src/cli/cli.ts:

• mcpb prepare-for-signing <file> — with -o/--output option
• mcpb apply-signature <file> -s <sig.p7s> — with -o/--output option

test/sign.e2e.test.ts:

• 8 new tests covering full roundtrip, rejection of signed/prepared/unprepared bundles, oversized signatures, padding correctness, adm-zip strict validation, and output path handling

Test results

• 227 tests passing (219 existing + 8 new), zero regressions
• Manual validation with real enterprise-signed bundle (1.4MB, 729 files)
• Structural comparison with Microsoft's signed Azure MCP bundles confirms format match
• Claude Desktop install test: PASS (bundle installs and initializes server)

Test plan

• All 227 tests pass (npm test)
• prepare-for-signing sets EOCD comment_length to 16384
• apply-signature produces valid ZIP (Python zipfile accepts)
• Signature block is exactly 16384 bytes (padded)
• file_size == eocd_offset + 22 + comment_length (adm-zip check)
• Output format matches Microsoft's Azure MCP signed bundles
• Claude Desktop install test with externally-signed bundle

🤖 Generated with Claude Code

/cc @asklar @vcolin7 — this generalizes the signing pattern from your Azure MCP Server pipeline (eng/scripts/Stage-McpbForSigning.ps1 + Apply-McpbSignatures.ps1) into the CLI. Would appreciate your review since your bundles are the reference implementation.